n can be greater than the buffer size of the number of free slots in the queue. These conditions must be checked.

There does seem to be an issue here, but it is not so trivial to pinpoint the exact data race with a loop around of the buffer that triggers it.

I will need some time to figure this one out.

There was an issue in the tests. The stopping condition was not correctly implemented when CONSUMERS * BATCH_SIZE > CAPACITY. This is now fixed.

In general, the issue you are describing can occur already when CONSUMERS * BATCH_SIZE > CAPACITY, meaning this can already happen with a lot of consumer threads even with single optimist push'es and pop's.

The good news this is not a problem for deadlocking (when properly dealing with the (batched) optimist queue). I shall sketch why this is the case later. Tests have been added to cover this case. The bad news is that when CONSUMERS * BATCH_SIZE > CAPACITY, push'es and pops can happen out of order. For example, two producers can be allocated slots head_1 and head_2 with head_1 < head_2 and head_1 % CAPACITY == head_2 % CAPACITY and it can happen now that the producer with allocated slot head_2 push'es first to the slot and the producer with allocated slot head_1 has to wait. This is an issue in so far as the queue no longer acts as "FIFO". The sketch as to why this does not deadlock is that one can imagine that the two producers swap "roles" when this happens, i.e. you swap the data that would be pushed to head_1 and head_2 and now just pretend that it was the first producer corresponding to head_1 that did the push and the second producer is the one waiting. (I need to write this down better)

The case BATCH_SIZE > CAPACITY is not an issue, it just means the producer has to wait until consumers pop'ed enough for the producer to continue push'ing.

In general, the issue you are describing can occur already when CONSUMERS * BATCH_SIZE > CAPACITY, meaning this can already happen with a lot of consumer threads even with single optimist push'es and pop's. The good news this is not a problem for deadlocking (when properly dealing with the (batched) optimist queue). I shall sketch why this is the case later. Tests have been added to cover this case.

README mentions this queue-full condition. Queue code-paths intend to handle it with no extra costs. The unit-test tests the queue-full condition by pushing orders of magnitude more messages than the queue capacity.

The bad news is that when CONSUMERS * BATCH_SIZE > CAPACITY, push'es and pops can happen out of order. For example, two producers can be allocated slots head_1 and head_2 with head_1 < head_2 and head_1 % CAPACITY == head_2 % CAPACITY and it can happen now that the producer with allocated slot head_2 push'es first to the slot and the producer with allocated slot head_1 has to wait.

For a slot, pop#0 waits for push#0 to complete. When wrapped head_ reaches unconsumed tail_, push#1 has to wait for pop#0 to complete. An unconsumed slot blocks any subsequent push into the slot.

An extreme case is a queue with 1 slot used by >=2 producers and >=2 consumers, all doing only optimistic push/pop. Which makes all producers to compete in push and all consumers to compete in pop, for one slot.

This is an issue in so far as the queue no longer acts as "FIFO". The sketch as to why this does not deadlock is that one can imagine that the two producers swap "roles" when this happens, i.e. you swap the data that would be pushed to head_1 and head_2 and now just pretend that it was the first producer corresponding to head_1 that did the push and the second producer is the one waiting. (I need to write this down better)

The current zero-cost solution for this scenario is queue capacity >= max(n_consumers, n_producers), in which case only 1 producer can ever get blocked on an unconsumed slot. But there are no unit-tests or asserts making sure that capacity >= max(n_consumers, n_producers) because the queues don't require the actual number of its producers/consumers to be specified in order to be declared or constructed.

A queue member function can be added to perform this check, if/when the caller has n_consumers, n_producers numbers available.

The queues are designed for low latency, which requires the user to ensure that condition capacity >= max(n_consumers, n_producers) holds true. FIFO order / fairness property emerges at zero-cost when there are no multiple competing producers or consumers for a slot. That's quite neat, but little else than serendipity -- unplanned greatness, rather than the objective. Maintaining FIFO order has non-zero cost, in general, because it requires delaying progress of competing threads. Which conflicts with the low latency objective, incompatible with delaying anything.

Hitting queue-full condition, though, defeats the objective of using these queues in the first place. This condition means the queue is not drained fast enough. Full queues guarantee only the worst latencies.

Guaranteeing FIFO order requires disabling thread preemption while in user-space critical sections, to prevent descheduling threads before they complete and unlock critical sections. Without being able to disable thread preemption for user-space critical sections, FIFO order / fairness is not possible in principle, and not worth burning a single CPU cycle for.

The kernel blocks and queues mutex/futex waiter threads as they arrive and unlocks them in the original FIFO order of blocking. std::condition_variable::wait guarantees FIFO order only when its associated std::mutex is locked prior to calling std::condition_variable::wait and unlocked only after calling std::condition_variable::notify*. These are original POSIX Threads API requirements/guarantees, adopted by C++ verbatim, with C++ multi-threading APIs being little else than thin wrappers for POSIX Threads API. (I abandoned using Windows for Linux in 2003, and wouldn't be able to comment on anything else than Linux.)

Sun OS exposed functions to disable interrupts/preemption of threads from user-space and one could call those directly. Sun's C standard library implementation disabled interrupts/preemption in pthread_mutex_lock/pthread_spin_lock and re-enabled them in pthread_mutex_unlock/pthread_spin_unlock, for example, to prevent preempting threads in the middle of critical sections after locking a mutex but before unlocking it. And that was the most desirable OS behaviour.

The Linux kernel uses all these capabilities preventing de-scheduling threads while holding spin-locks and futexes in its kernel code. But doesn't expose any of these to user-space code because users would only ever deadlock themselves in their spin-locks with interrupts disabled, and that's like giving matches to toddlers.

Same issue here.